前言

在上一篇文章中，我整理了不同醫院的資料無法直接互通的原因。

即使兩家醫院都保存病人的姓名、生日、診斷和檢驗結果，仍可能因為資料格式、欄位名稱、醫療代碼及系統版本不同，無法直接讀懂彼此的資料。

為了解決這些問題，醫療資訊領域逐漸發展出共同的資料交換標準。

提到醫療資料交換時，最常聽見的名稱之一就是「HL7」。而這個系列的主角FHIR，也同樣是由HL7制定的標準。

今天就來認識HL7，並簡單整理醫療資料交換標準從HL7 v2、HL7 v3一路發展到FHIR的過程。

HL7是什麼？

HL7的完整名稱是：

Health Level Seven International

HL7 International成立於1987年，是一個制定醫療資訊標準的非營利組織。

它的目標不是替醫院開發掛號或電子病歷系統，而是建立醫療資訊交換的標準，讓不同系統能以共同的方式交換、整合及使用電子健康資訊。

因此，「HL7」這個名稱可能在不同情境中代表：

1. HL7 International這個標準制定組織
2. 由HL7制定的一系列醫療資訊標準
3. 實務上經常使用的HL7 v2訊息

所以當別人提到「系統要傳HL7」時，通常還需要進一步確認，對方指的是哪一種HL7標準及版本。

為什麼名稱中有一個7？

HL7名稱裡的「Level Seven」，來自OSI網路模型中的第七層，也就是應用層。

OSI模型將電腦網路通訊分成七個層次：

應用層關注的是應用程式之間如何交換有意義的資料。

以醫療系統來說，重點不只是把資料透過網路傳送出去，還要讓接收方知道：

• 這是一筆病人資料。
• 這是一張檢驗醫令。
• 這是一項檢驗結果。
• 這是病人的入院或出院通知。
• 每個欄位分別代表什麼。

因此，HL7主要關心的是醫療應用系統之間交換資料時所需要的結構、內容及意義。

HL7不是只有一個版本

HL7並不是一套從以前到現在完全不變的格式。

隨著醫療資訊需求及資訊技術不斷發展，HL7制定了不同的標準系列，其中常見的包括：

• HL7 Version 2
• HL7 Version 3
• CDA
• FHIR

它們並不是單純像手機作業系統一樣，推出新版後舊版就立刻停止使用。醫療系統通常需要長期穩定運作，因此不同世代的標準可能同時存在於實際環境中。

HL7 Version 2：醫療系統中的訊息交換

HL7 Version 2通常簡稱為：

HL7 v2

HL7 v2是醫療領域廣泛使用的訊息交換標準。它適合處理醫療流程中發生的各種事件，例如：

• 病人完成掛號
• 病人住院
• 病人轉床
• 病人出院
• 醫師開立檢驗醫令
• 檢驗系統回傳結果
• 系統更新病人基本資料

這些事件發生時，系統可以建立對應的HL7 v2訊息，再傳送給其他系統。

HL7 v2訊息長什麼樣子？

下面是一段經過簡化的HL7 v2示意訊息：

MSH|^~\&|HIS|HOSPITAL|LIS|HOSPITAL|202609030900||ORM^O01|123456|P|2.5
PID|1||P001||王^小明||20000101|M
ORC|NW|ORDER001
OBR|1|ORDER001||BLOOD_TEST

第一次看到時，可能會覺得這串內容非常像密碼。

其實，HL7 v2訊息通常由多個「Segment」組成，每一行都有不同用途。

在上面的簡化範例中：

• MSH表示訊息標頭。
• PID記錄王小明的基本資料。
• ORC表示一筆新的醫令。
• OBR表示要執行的檢驗項目。

HL7 v2常使用|、^等符號分隔資料。系統必須依照欄位的位置及規則，才能知道每一段資料代表什麼。

HL7 v2如何用在醫院？

假設醫師替王小明開立抽血檢驗。

簡化後的資料流程可能是：

1. 醫師在HIS或醫令系統中開立檢驗。
2. 系統產生一則HL7 v2醫令訊息。
3. 訊息被傳送到LIS。
4. LIS解析訊息，取得病人及檢驗項目。
5. 檢驗完成後，LIS建立結果訊息。
6. 結果訊息再傳回HIS或電子病歷系統。

透過共同的訊息格式，HIS與LIS就不必完全使用相同的程式或資料庫，也能進行資料交換。

HL7官方將Version 2系列形容為臨床領域電子資料交換的重要基礎，也是目前廣泛實作的標準之一。

HL7 v2的優點

HL7 v2能被廣泛使用，有幾項重要原因：

• 適合傳送醫療流程中的事件訊息。
• 已經在許多醫療機構中累積長期使用經驗。
• 可以交換掛號、住院、醫令及檢驗結果等資料。
• 允許醫療機構依照需求進行調整。
• 許多既有醫療系統及設備已經支援。

對醫院來說，穩定和相容性非常重要。即使有新技術出現，已經長期運作的HL7 v2介面也不一定會立刻被替換。

HL7 v2帶來的挑戰

HL7 v2保留一定的彈性，讓不同醫院可以配合自己的需求實作，但彈性也可能造成差異。

例如，同一項資料在不同醫院可能：

• 放在不同欄位
• 使用不同代碼
• 將選填欄位當成必填
• 使用自行定義的Segment
• 對同一版本採取不同實作方式

因此，即使兩套系統都支援HL7 v2，實際串接時仍然需要確認雙方使用的：

• HL7版本
• 訊息類型
• Segment
• 欄位位置
• 必填及選填規則
• 代碼表
• 傳輸方式
• 錯誤處理方式

HL7 v2提供了共同基礎，但不代表兩套系統接上後就一定能立刻交換所有資料。

HL7 Version 3：希望建立更一致的資料模型

為了讓標準的定義更加明確及一致，HL7後續發展了HL7 Version 3，也就是：

HL7 v3

HL7 v3採用較嚴謹、模型導向的設計方式，並以Reference Information Model，簡稱RIM，作為重要基礎。

相較於HL7 v2提供較多實作彈性，HL7 v3希望透過共同的資訊模型，減少不同系統對相同資料產生不同解讀的情況。

HL7 v3的訊息通常使用XML表示。XML具有明確的開始與結束標籤，相較於依賴欄位位置的格式，資料名稱較容易被辨認。

簡化的XML資料可能類似：

<patient>
  <id>P001</id>
  <name>王小明</name>
  <gender>male</gender>
  <birthDate>2000-01-01</birthDate>
</patient>

從這段資料可以直接看見id、name、gender及birthDate等標籤，不需要只依靠欄位順序猜測資料內容。

CDA：以文件為中心交換臨床資料

介紹HL7 v3時，也經常會看到CDA。

CDA的全名是：

Clinical Document Architecture

中文可以理解為「臨床文件架構」。

CDA是以XML為基礎的臨床文件標準，用來規範臨床文件的結構和語意。

可能使用CDA表達的內容包括：

• 出院病歷摘要
• 轉診摘要
• 檢查報告
• 門診摘要
• 其他臨床文件

CDA文件通常同時重視兩個面向：

1. 讓醫療人員能閱讀文件內容。
2. 讓資訊系統能處理其中的結構化資料。

可以將CDA想像成一份具有標準結構的電子醫療文件。它與稍後要介紹的FHIR Resource，在資料組織概念上不完全相同。

為什麼還要發展FHIR？

雖然HL7 v2、v3及CDA已經能夠處理許多醫療資料交換需求，但隨著Web、行動裝置及雲端服務發展，醫療資訊系統也需要更容易使用現代Web技術進行交換的方式。

FHIR的全名是：

Fast Healthcare Interoperability Resources

FHIR同樣由HL7制定，並吸收過去醫療資訊標準累積的經驗，再搭配現代Web開發中常見的技術與設計概念，例如：

• HTTP
• RESTful API
• URL
• JSON
• XML
• OAuth等授權方式

對已經接觸過Web API的開發者來說，這些技術比較熟悉，也比較容易使用一般的Web開發工具測試。

FHIR和過去標準最大的概念差異

FHIR的一項核心概念是Resource。

它將醫療及行政資料拆分成不同類型的Resource，例如：

• Patient：病人
• Practitioner：醫療人員
• Organization：機構
• Encounter：就醫事件
• Observation：觀察或檢驗結果
• Condition：疾病或診斷
• MedicationRequest：用藥醫令

每一種Resource都有自己的資料結構，也可以透過Reference與其他Resource建立關係。

例如，一筆Observation可以透過Reference指出這項檢驗結果屬於哪一位Patient。

FHIR也能透過RESTful API操作Resource，例如：

GET /Patient/123

表示讀取ID為123的Patient Resource。

GET /Observation?patient=123

表示搜尋與該病人有關的Observation Resource。

這種方式與一般Web API的操作概念較為接近。

用寄送資料的方式比較

如果用日常生活中的資料傳送方式來比喻：

HL7 v2像是固定格式的即時通知

當病人掛號、住院、轉床或完成檢驗時，系統立刻傳送一則具有固定欄位順序的訊息。

重點在於：

發生一個事件後，將訊息通知另一個系統。

CDA像是一份具有標準格式的正式文件

它包含文件標題、內容及不同段落，可供醫療人員閱讀，也能放入結構化資料。

重點在於：

交換一份完整且具有臨床意義的文件。

FHIR像是透過Web API操作醫療資料積木

系統可以依照需求查詢Patient、Observation或Encounter，也可以新增及更新Resource。

重點在於：

將資料拆成標準化Resource，再透過API進行操作與交換。

這只是協助初學者理解的簡化比喻，實際標準的功能和使用情境會更加複雜。

HL7 v2、v3、CDA與FHIR比較

FHIR會完全取代HL7 v2嗎？

從初學者的角度，很容易把FHIR理解為HL7 v2的「新版」，並認為醫院未來只要全面改用FHIR即可。

實際上並沒有這麼簡單。

許多醫院既有系統已經透過HL7 v2穩定交換資料。如果直接替換，不只需要修改程式，還可能影響檢驗、醫令、掛號及其他重要流程。

因此，實際環境中可能同時存在：

• 院內系統繼續使用HL7 v2交換即時訊息。
• 臨床摘要使用CDA文件。
• 對外服務或新應用使用FHIR API。
• 透過整合平台將不同格式互相轉換。

FHIR不是把以前的標準全部推翻，而是在既有經驗上，提供另一種符合現代資訊技術的交換方式。

從演變過程學到什麼？

整理HL7標準的演變後，我發現醫療資料交換並不是突然從FHIR開始。

HL7 v2、v3及CDA都在不同時期處理了重要需求，也累積了許多醫療資料標準化的經驗。

FHIR的特色，是將這些醫療資訊概念與現代Web技術結合，透過Resource及API提供較容易開發與操作的方式。

不過，不論使用哪一種標準，最重要的目標都沒有改變：

讓不同醫療資訊系統能正確、安全地交換並使用醫療資料。

今日小結

今天認識了HL7 International及幾種常見的HL7標準。

HL7既是一個標準制定組織，也常被用來泛指它所制定的醫療資訊標準。HL7 v2著重醫療事件訊息交換；HL7 v3採用更嚴謹的模型導向設計；CDA著重具有標準結構的臨床文件；FHIR則以Resource為核心，並結合RESTful API、JSON等現代Web技術。

這些標準不一定互相排斥，也可能同時存在於醫院資訊環境中。

下一篇將正式進入這個系列的主角，從FHIR名稱、核心概念及特色開始，完整認識FHIR。

明日預告

Day 6｜FHIR是什麼？先從名稱開始認識

參考資料

1. HL7 International：About HL7
   https://www.hl7.org/about/

2. HL7 International：Introduction to HL7 Standards
   https://www.hl7.org/implement/standards/

3. HL7 International：HL7 Version 2 Product Suite
   https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185

4. HL7 International：HL7 Version 3 Product Suite
   https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186

5. HL7 International：CDA Release 2
   https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7

6. HL7 FHIR R4官方規範
   https://hl7.org/fhir/R4/